esp@cenet document view 



Page 1 of 1 



Motor vehicle remote monitoring service for diagnosis of motor vehicle 
systems and control systems via a wireless Interface, e.g. via a GSM link, 
whereby diagnosis functions are divided between central server and onboard 

terminal 



Publication number: 

Publication date: 

Inventor: 

Applicant: 

Classification: 
- international: 



- European: 

Application number: 
Priority number(5): 



DE1 0257030 
2003-12-18 

SONNENREIN THOMAS (DE); BAUER NORBERT (DE) 
BOSCH GMBH ROBERT (DE) 

B60R16/02; B60R25/00; G07C5/00; H04L12/56; 
H04L29/06; B60R16/02; B60R25/00; G07C5/00; 
H04L12/56; H04L29/06; (IPC 1-7): G06F15/163 

B60R16/023D3H; B60R25/00i G07C5/00T; H04L12/56B; 
H04L29/06 

DE20021057030 20021206 

DE20021057030 20021206; DE20021025788 20020610 



Also published as: 

Q DEI 0254284 (A1) 



Report a data error here 



Abstract of DE1 0257030 

Motor vehicle remote monitoring service method 
in which a central server connects to an onboard 
terminal via a communications network. The 
remote monitoring service is divided into partial 
functions, which are divided between server and 
terminal with time critical functions running on the 
terminal and time-independent functions running 
on the server. Independent claims are made for a 
remote monitoring device in which remote 
diagnosis service functions divided between a 
central server and an onboard terminal with time 
critical functions running on the terminal and 
time-independent functions running on the 
server. 
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(g) Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst 

(57) Eswerden ein Verfahren und eine Vorrichtung fiir einen 
fahrzeugbezogenen Telematikdienst vorgeschlagen, bei 
welchem der Telematikdienst In Teilfunktionalitaten un- 
tergliedert ist und diese Teilfunktionalitaten auf Server 
und Endgerat aufgeteilt sind. 
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Beschreibung 

Stand der Technik 

[0001] Die Erfindung betrifft ein Verfahren und Vorrich- 5 
tung fur einen fahrzeugbezogenen Telematikdienst wie das 
Einwirkcn auf wcnigstcns cine Funktionalitat in cinem 
Fahrzeug uber cine Luftschnitts telle, z. B. ein Mobilfunk- 
netz, insbesondere in Verbindung mit der Femdiagnose von 
Kraftfahrzeugen. 10 
[0002] Die zunehmende Vemetzung von Steuergeraten in 
heutigen Kraftfahrzeugen bietet immer bessere Einwir- 
kungsmoglichkeiten auf Funktionalitaten im Kraftfahrzeug, 
z. B. bessere Diagnosemoglichkeiten im Fehlerfall oder 
Moglichkeiten zur Fembedienung von Funktionen und/oder 15 
Komponenten des Fahrzeugs. In diesem Zusammenhang be- 
stehen Konzepte, mit Hilfe eines mobilfunkgestiitzten Ein- 
wirkens zuverlassig und sicher auf die Funktionalitat im 
Fahrzeug iiber beliebige Entfemungen hinweg zuzugreifen, 
beispielsweise iiber eine Femdiagnose zuverlassige und 20 
qualitativ hochwertige Fehleranalysen durch ein Service- 
Center bzw. einen Ferndiagnose-Server, der eine entspre- 
chende Diagnose-Datenbank umfasst, durchzufiihren. Ge- 
maB diesen Ansatzen werden im Fahrzeug integrierte Kom- 
munikationssysteme wie beispielsweise Mobiltelefone und/ 25 
oder GSM-gestutzte Telematikendgerate genutzt, um eine 
Dateniibertragung zwischen den an ein Fahrzeugnetzwerk 
angeschlossenen Steuergeraten und/oder Komponenten und 
dem Server des Service-Centers durchzufuhren. Einen Vor- 
schlag fiir ein derartiges System beschreibt die 30 
DE 100 26 754 Al. Eine konkrete Realisierung hinsichtlich 
der Ubertragungsinhalte zwischen Server und Endgerat so- 
wie hinsichtlich der Ausgestaltung von Endgerat bzw. Ser- 
ver werden nicht angegeben. 

35 

Vorteile der Erfindung 

[0003] Durch die Aufteilung der Funktionen, z. B. Dia- 
gnosefunktionen, zwischen Endgerat und Server (Partitio- 
nieren von Teilfunktionen) wird eine erhebliche Ressour- 40 
cenersparnis im Fahrzeugendgerat erreicht. Besonders vor- 
teilhaft ist, dass zeitunkritische, fahrzeugspezifische Funk- 
tionen, mit denen das Einwirken auf die ausgewahlte Funk- 
tionalitat gesteuert wird, nicht im Fahrzeugendgerat, son- 
dem im Server vorgehalten werden und von diesem iiber die 45 
Luftschnittstelle iibertragen werden. Dadurch wird vermie- 
den, dass ein zusatzliches, speziell auf die Anwendung ins- 
besondere hinsichtlich vom Fahrzeugnetzwerk voi^egebe- 
nen zeitlichen Randbedingungen zugeschnittenes Applikati- 
ons-ProtokoU fur die Luftschnittstelle notwendig ist, so dass 50 
auf iibHche Standard-ProtokoUe fur die Luftschnittstelle zu- 
riickgegrififen werden kann. Erganzend erlaubt die Uber- 
mittlung von fahrzeugspezifischen Informationen iiber die 
Luftschnittstelle eine einheitliche, parametrisierbare Funk- 
tionalitat im Endgerat sowie eine fahrzeugunabhangige Im- 55 
plementierung im Endgerat. Eine besonders hohe Flexibili- 
tat des Systems wird erreicht, die sich auch sich andemde 
Ausstattungen der Fahrzeuge anpassen kann. 
[0004] Bci der Femdiagnose sind Andcrungcn oder Vcr- 
besserungen im Bezug auf die Diagnose selbst, sofern diese 60 
nicht Onboard in den Steuereinheiten des Fahrzeugs ablau- 
fen, im Server moglich. Dies betrifft vor alien den Ablauf 
und Umfang (iibertragene Daten) des Femdiagnosevor- 
gangs. 

[0005] Besondere Vorteile werden in Verbindung mit der 65 
Femdiagnose erreicht, wenn die Kommandos des fahrzeug- 
spezifischen Diagnose-Protokolls iiber die Luftschnittstelle 
vom Server zum Endgerat iibertragen werden. 



[0006] Durch die Ressourcenerspamis im Fahrzeugendge- 
rat, insbesondere durch die Auslagerung zeitunkritischer 
Vorgange in den Server des Service-Centers wird eine einfa- 
che und schnelle Umsetzung auf das Fahrzeugnetzwerk im 
Endgerat mogfich. 

[0007] Somit ergibt sich insgesamt eine effiziente und vor 
allcm mit gcringcm Auf wand implcmcnticrbarc \brgchcns- 
weise zum Einwirken auf eine Fahrzeugfunktionalitat, vor 
allem zur Femdiagnose, Femwartung, Femsteuemng, Soft- 
ware-Download, etc. bei Kraftfahrzeugen. 
[0008] Weitere Vorteile ergeben sich aus der nachfolgen- 
den Beschreibung von Ausfiihmngsbeispielen bzw. aus den 
abhangigen Patentanspriichen. 

Zeichnung 

[0009] Die Erfindung wird nachstehend anhand der in der 
Zeichnung dargestellten Ausfiihrnngsformen anhand der 
Femdiagnose eines Kraftfahrzeugs naher erlautert. 
[0010] Fig, 1 zeigt ein Prinzipbild eines Femdiagnosesy- 
stems. 

[0011] In Fig, 2 ist als Ubersichtsdarstellung die Auftei- 
lung der Diagnosefunktionalitat zwischen fahrzeugseitigem 
und serverseitigem Teil des Systems dargestellt. Insbeson- 
dere ergeben sich daraus auch Ausgestaltungen des Fahr- 
zeugendgerats bzw. des Servers des Service- Centers. 
[0012] Fig. 3 zeigt ein Ablaufdiagramm, welches den 
gmndsatzlichen Ablauf der Femdiagnose insbesondere im 
Hinblick auf die Ubertragung zwischen Server und Endgerat 
sowie im Hinblick auf die Funktionen des Endgerats bzw. 
des Servers in einem bevorzugten Ausfiihrungsbeispiel dar- 
stellt. 

[0013] Fig. 4 zeigt die Kommunikation zwischen Server 
und Endgerat sowie zwischen Endgerat und zu diagnostizie- 
rendem Steuergerat sowie die in den jeweiligen Einheiten 
ablaufenden Vorgange im Detail anhand eines bevorzugten 
Ausfuhmngsbeispiels . 

Beschreibung von Ausfiihmngsbeispielen 

[0014] Fig. 1 zeigt ein Ubersichtsbild eines Systems fiir 

einen fahrzeugbezogenen Telematikdienst, wobei Informa- 
tionen zwischen einem Fahrzeug (dort Endgerat) und einem 
Server iiber ein Mobilfunknetz bzw. Uber ein Datennetz, wie 
beispielsweise das Internet, ausgetauscht werden. Eine der- 
artige Konfiguration wird in Verbindung mit Funktionen zur 
Femwirkung, Femdiagnose, Fernwartung, Software 
Download, etc. eingesetzt. Unter Femwirkung bzw. Femab- 
frage wird dabei im wesentlichen die Femsteuemng von 
Fahrzeugfunktionen, insbesondere Komfortfunktionen wie 
das Einschalten der Standheizung, etc., sowie das Abfragen 
von Fahrzeugstati und/oder Betriebsparametem verstanden. 
Dabei initiiert der Nutzer eine Kommunikation mit dem 
Fahrzeug iiber einen zentralen Serv^er oder er kommuniziert 
direkt mit dem Fahrzeug. Femdiagnose umfasst das Fem- 
auslesen von Diagnosedaten aus dem Fahrzeug, deren Ana- 
lyse und ggf. das Erzeugen einer Empfehlung fiir das weiter- 
gehende Handeln. Analyse der Daten und Generiemng der 
Empfehlung crfolgt dabei durch einen zentralen Server, der 
mit dem Fahrzeug iiber ein Mobilfunknetz, iiber ein drahtge- 
bundenes Netz und/oder iiber ein Datennetz wie beispiels- 
weise das Internet mit dem Kraftfahrzeug in Verbindung 
steht. Femer ist in diesem Zusammenhang als Funktion der 
sogenannte Software-Download bzw. das Remote- Flashing 
zu nennen, mit deren Hilfe ein neuer Programmcode oder 
Parameter auf per Software konfigurierbare Systeme im 
Fahrzeug, beispielsweise Steuergerate, aufgebracht werden, 
um die Funktionalitaten oder die Leistungsfahigkeit zu er- 
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hohen. Auch hier erfolgt die Kommunikation uber ein Mo- 
bilfunknetz, ein drahtgebundenes Netz und/oder beispiels- 
weise das Internet ausgehend von einem zentralen Rechner 
(Server) bzw. Service-Center. Femwartung stellt iiii wesent- 
lichen die Uberwachung des Fahrzeugzustandes und den 5 
Zugriff auf die Wartungsdaten im Fahrzeug von einer zen- 
tralen S telle aus dar, um zu ubcrpriifcn, ob, wann und wcl- 
che MaBnahmen zur Wahmng des Sollzustandes durchge- 
fiihrt werden. Ein Beispiel hierfur ist das dynamische An- 
passen von Wartungsintervallen. Allgemein werden diese 10 
Funktionalitaten hier unter dem Begriff des fahrzeugbezo- 
genen Telematikdienstes subsumiert. 

[0015] Fig, 1 zeigt einen fahrzeugseitigen Teil 1 sowie ei- 
nen serverseitigen Teil 2. Beide Telle sind liber eine Kom- 
munikationsschnittstelle 3, insbesondere eine Luftschnitt- 15 
stelle, beispielsweise iiber ein Mobilfunknetz miteinander 
verbunden. Der fahrzeug seitige Teil besteht aus einem End- 
gerat 4, beispielsweise einem Telematikendgerat, welches 
iiber eine weitere Schnittstelle 5 mit der Fahrzeugelektronik 
6 verbunden ist. Der serverseitige Teil 2 besteht aus einem 20 
Server 7, welcher beispielsweise von einem Service- Center, 
dem Fahrzeughersteller oder einem Zulieferer betrieben 
wird, und der iiber eine Schnittstelle 8 mit einem Datenspei- 
cher 9 in Verbindung steht, in dem beispielsweise im Rah- 
men einer Datenbank fahrzeugbezogene Daten und/oder 25 
Kommandos und/oder Programme abgelegt sind. Wie nach- 
folgend im Detail beschrieben, werden bei dem dargestell- 
ten Client-Serv^er- System Teilfunktionen parti tioniert, d. h. 
dem Server und den Client bestimmte Funktionalitaten eines 
Telematikdienstes zugeordnet. Dabei wird von einer voll- 30 
standigen Vernetzung der zu diagnostizierenden bzw. zu 
steuernden Steuergerate im Fahrzeug mit dem Endgerats 
z. B. durch einen CAN-Bus sowie von der Verfiigbarkeit der 
Schnittstelle 3, insbesondere einer Mobilfunkschnittstelle 
im Kraftfahrzeug, ausgegangen. Die bekannten, unter- 35 
schiedlichen Verfahren fiir die Erfassung von Diagnoseda- 
ten, beispielsweise iiber eine CAN-Bus-Schnittstelle, lassen 
sich in nichtzeitkritische und zeitkritische Anwendungen 
aufteilen. Zu den nichtzeitkritischen Anwendungen gehort 
beispielsweise die Ablaufsteuerung des Diagnose-Testers, 40 
mit Zugriff auf eine Datenbank, sowie das Diagnose-Proto- 
koU selbst, beispielsweise das Protokoll KWP2000 bzw. Va- 
rianten davon. Zeitkritische Anwendungen sind das Trans- 
port-Protokoll des Falirzeugnetzes (z. B. CAN-Transport- 
Protokoll) oder Varianten davon, des sen Kommunikations- 45 
schicht (z. B. CAN-Kommunikationsschicht) sowie der Bus 
(z. B. CAN-Bus) selbst. Wesentlich ist, dass bei der Imple- 
mentierung der Telematikfunktion im Kraftfahrzeug die 
zeitkritischen Vorgange gegeniiber dem unsichereren Mo- 
bilfunkkanal entkoppelt werden. Daher werden alle oder ein 50 
Teil der relevanten Funktionen aus dem Fahrzeug ausgela- 
gert, bei denen keine engen zeitlichen Anforderungen beste- 
hen, insbesondere Anforderungen beziigliche einer minima- 
len oder maximalen Zeitdauer zwischen Kommando und 
Antwort bei einer Dateniibertragung. Im Extremfall bleibt 55 
daher lediglich der zeitkritische Datentransport auf dem 
Fahrzeug-Bus (z. B. CAN-Bus oder Ahnliches), welcher 
durch Funktionen des Transport-ProtokoUs wie beispiels- 
weise die Fragmcnticrung und Dcfragmcnticrung komplc- 
xer Nachrichten, realisiert ist, auf der Calient- bzw. Fahr- 60 
zeugseite zuriick. Der Funktionsumfang des in der Regel 
komplexeren und fahrzeugspezifischen Dienste-Protokolls 
(z. B. Diagnoseprotokoll) wird dabei auf einen entsprechen- 
den Server (z. B. Diagnose server) ausgelagert. Im Anwen- 
dungsfall der Ferndiagnose werden neben der Ubertragung 65 
fahrzeugspezifischer Diagnose-Kommandos auf der Basis 
des jeweils verwendeten Diagnose-Protokolls femer zusatz- 
liche Inforaiationen zwischen der Server- Applikation (Ab- 
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laufsteuerung fiir den Gesamtvorgang) und der Client- App- 
likation (Ablaufsteuerung zur Datenerfassung) iibeitragen. 
Diese Ablaufsteuerungen dienen der Aktivierung des Dia- 
gnosevorgangs, der Konfiguration der Client-Applikation 
und der spateren Ubermittlung von Ergebnissen der server- 
seitigen Datenanalyse. In dem skizzierten Beispiel, bei dem 
alle zcitunkritischcn Voigangc aus dem fahrzeugseitigen 
Teil in den serverseitigen Teil des Systems ausgelagert wur- 
den, ergibt sich die in Fig, 2 dargestellte Systemarchitektur. 
In anderen Ausfiihrungen wird nur ein Teil der nichtzeitkri- 
tischen Vorgange ausgelagert, wahrend ein Teil im fahr- 
zeugseitigen Endgerat verbleibt. So ist beispielsweise vor- 
stellbar, dass fahrzeugspezifische Daten und/oder spezielle 
fahrzeugspezifische Diagnose-Kommandos, die aus Sicher- 
heitsgriinden nicht ausgelagert werden, im fahrzeugseitigen 
Teil des Systems verbleiben. 

[0016] In Verbindung mit anderen Telematikdiensten wie 
der Femsteuerung von Komponenten, den Software- 
download, etc. wird auf die geschilderte Art und Weise zei- 
tunkritische Anwendungen ausgelagert, wahrend zeitkriti- 
sche Anwendungen im Fahrzeugendgerat verbleiben. 
[0017] In Fig. 2 ist das Fahrzeugendgerat (Client) 4 sowie 
der Server 7 dargestellt, welche iiber eine Luftschnittstelle 3 
miteinander verbunden sind. Im bevorzugten Ausfiihrungs- 
beispiel handelt es sich bei der Luftschnittstelle 3 um ein 
herkommliches, beispielsweise auf dem GSM-Standard ba- 
sierendes Mobilfunknetz. In anderen Anwendungen handelt 
es sich um Mobilfunknetze, die mit anderen Standards ar- 
beiten. Der Server umfasst die folgenden Module: ein Mo- 
bilfunk-Kommunikations-Protokoll-Modul 7a, ein Mobil- 
funkkommunikation-Modul 7b, ein Ablaufsteuerungs-Mo- 
dul 7c sowie ein fahrzeugspezifisches Diagnose-ProtokoU- 
Modul 7d. Das Fahrzeugendgerat umfasst ebenfalls ein 
Kommunikations-ProtokoU-Modul 4a, ein Modul 4b zur 
Kommunikation iiber die Mobilfunkschnittstelle, ein Modul 
4c zur CAN- Kommunikation sowie ein Transport-Proto- 
koll-Modul 4d. Ferner ist eine Ablaufsteuerung 4e im Fahr- 
zeugendgerat vorgesehen. Die Module stellen dabei vor- 
zugs weise Softwareprogramme dar. 

[0018] Diese Funktionseinheiten haben die folgenden 
Aufgaben: 

Die Mobilfunkkommunikations-Module 4b, 7b, die sowohl 
im Endgerat als auch im Server vorgesehenen sind, diesen 
zur stabilen Dateniibertragung, zum Verbindungsaufbau 
bzw. -abbau, der Datensicherheit, gegebenenfalls der Ver- 
se hliisselung, Packetierung, etc. Diese Aufgaben werden 
von liblichen Kommunikationsfunktionseinheiten realisiert 
und sind z. B. im Rahmen der GSM-Standards verfiigbar. 
[0019] Das im Fahrzeugendgerat vorgesehene CAN- 
Kommunikation-Modul 4c stellt eine hardwareunabhangige 
Softwareschnittstelle zur Ubertragung von Daten iiber einen 
CAN-Bus zu angeschlossenen Steuergeraten dar. Dazu ge- 
horen die Initialisierung und Steuerung des CAN- Control- 
lers, die Ubertragung und den Empfang von CAN-Baustei- 
nen sowie Uberlauf-Fehlerbehandlungen und Weckfunktio- 
nen. Femer umfasst das Modul die Funktionen der OSI- 
Layer 1 und 2 (Physical Layer, Data Link Layer). Das Soft- 
waremodule arbeitet dabei im Rahmen der giiltigen CAN- 
Spczifikation. In anderen Ausfiihrungen wird anstcllc des 
C^AN-Bus ein anderes Bussysteme eingesetzt (standardisiert 
oder kundenspezifisch), wobei das Softwaremodul dann auf 
der Basis einer entsprechenden Spezifikation realisiert ist. 
[0020] Die Ablaufsteuerung 7c im Server zerlegt die Dia- 
gnose-Grundfunktionen in einzelne Teilprozesse bzw. Dia- 
gnose-Services, iibernimmt die Initialisierung des Prozes- 
ses, steuert und beendet den Diagnosevorgang, verarbeitet 
die erforderlichen Parameter- und gegebenenfalls Protokoll- 
Mechanismen fiir den Diagnosevorgang und steuert den Ge- 
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samtvorgang zeitlich. Femer werden hier die ermittelten 

Diagnosedaten ausgewertet, gegebenenfalls eine Generie- 
rung einer Empfehlung durchgefiihrt. Femer iibemimmt die 
Ablaufsteuerung den Zugriff auf die Diagnose-Datenbank 
des Servers. Die Ablaufsteuerung stellt ein Software-Modul 5 
dar, welches fur die spezielle Anwendung konzipiert ist. Ein 
Bcispicl wird nachfolgcnd anhand dcr Fcrndiagnosc in den 
Fig. 3 und 4 skizziert. 

[0021] In entsprechender Weise ist ein Ablaufsteuerungs- 
Modul 4e im Fahrzeugendgerat vorgesehen. Auch dieses 10 
Software-Modul ist fiir die spezielle Anwendung konzipiert. 
Ein Beispiel wird nachfolgcnd anhand der Femdiagnose in 
den Fig, 3 und 4 skizziert. Diese Ablaufsteuerung erzeugt 
eine Server- Anfrage zur Durchfiihrung einer Femdiagnose. 
Sie konfiguriert die Funktionen im Fahrzeug, beispielsweise 15 
durch Festlegen einer Tester-Present-Nachricht, Einstellen 
der Timing-Parameter fiir das Transport-ProtokoU und gege- 
benenfalls Einstellen der Parameter fiir die C AN-Kommuni- 
kation. Die Ablaufsteuerung fiihrt femer die Diagnose- 
Kommunikation durch zyklisches Generierung von Tester- 20 
Present-Nachrichten mit den zu diagnostizierenden Steuer- 
einheiten durch. Femer werden von ihr die vom Server iiber- 
tragenen Diagnose- Kommandos auf das CAN-Transport- 
Protokoll umgesetzt. Dariiber hinaus iibertragt das Ablauf- 
diagramm die Daten an den Server und setzt zu diesem 25 
Zweck die im Fahrzeug ermittelten Diagnose-Daten auf die 
Mobilfunkschnittstelle um. Dariiber hinaus sind MaBnah- 
men getroffen, mit denen in einem Ausfiihrungsbeispiel die 
bewerteten Ergebnisse der Fehleranalyse, die vom Server 
iibermittelt werden, angezeigt werden. Ferner iibemimmt 30 
die Ablaufsteuemng die Beendigung der Diagnose-Kom- 
munikation durch Stoppen der Generierung von Tester-Pre- 
sent-Nachrichten. Dariiber hinaus wird in einem Ausfiih- 
rungsbeispiel das automatische Beenden eines unterbroche- 
nen Diagnosevorgangs, z. B. durch Timeout oder Watchdog 35 
fur den Empfang von Serv^er- Kommandos, durchgefiihrt. 
[0022] Das im Client 4 vorgesehene Transport-Protokoll- 
Modul 4d fuhrt die Ubertragung von komplexen Nachrich- 
ten oder Dateneinheiten iiber einen CAN-Bus durch, nimmt 
die Entkopplung des Diagnose-Protokolls vom physikali- 40 
schen Ubertragungsmedium vor und stellt die Dienste des 
OSI-Layers 3 (Network Layer) zur Verfiigung, sowie die 
Verbindung zwischen dem OSI-Layer 2 (Data Link Layer) 
und 7 (Applikation Layer). Es werden als also vom Trans- 
port-Protokoll-Modul eine Segmentierung und Erfassung 45 
von Daten des Data Link Layers vorgenommen, das heiBt 
die Steuemng des Datenflusses einzelner Botschaften inklu- 
sive Verwaltung und Zuordnung von physikalischen CAN- 
Botschaften zu logischen Nachrichten oder Dateneinheiten 
sowde die Fehlererkennung. Eine Realisierung stellt das all- 50 
gemein verbreitete ISO-Transport-ProtokoU (ISO 15765-2) 
dar, wobei in anderen Anwendungen auch spezielle Varian- 
ten dieses ProtokoUs eingesetzt werden. Dies gilt auch bei 
der Verwendung anderer Bussysteme zur Kommunikation 
mit den Fahrzeugsteuergeraten. 55 
[0023] Das dem Server zugeordnete Diagnose-ProtokoU- 
Modul 7d umfasst die Diagnoseschicht, welche in einer be- 
vorzugten Anwendung das nach ISO spezifizierte Diagnose- 
ProtokoU KWP2000 cnthalt, wobci jc nach Ausfiihmngsbci- 
spiel auch Varianten davon eingesetzt werden. In diesem 60 
Diagnose-ProtokoU-Modul sind spezielle Diagnose-Dienste 
definiert, die je nach Kraftfahrzeughersteller und/oder 
Kraftfahrzeugtyp unterschiedlich genutzt werden und zum 
Teil unterschiedliche Zusatzdienste enthalten. Das Dia- 
gnose-Protokoll-Modul wertet die Diagnose- Anfragen aus. 65 
Weitere Aufgaben, die durch das Modul gelost werden, sind 
die Konvertiemng von Diensten in eine funktionale Schnitt- 
stelle fiir die Anwendungsschicht, die direkte Nutzung spe- 
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zieller Dienste und die Ausnahmebehandlung bei Nutzung 

von unbekannten Diensten. Ein Beispiel fiir die Realisie- 
rung eines solchen Modul ist aus den nachfolgcnd beschrie- 
benen Vorgehensweisen entnehmbar. 

[0024] Die grundsatzliche Vorgehensweise im Rahmen 
der Femdiagnose besteht darin, dass nach Aktiviemng der 
Femdiagnose durch cine Bcdicnpcrson, z. B. den Nutzcr des 
Kraftfahrzeugs, und/oder den Service-Provider und/oder 
den Fahrzeughersteller und/oder eines Monteurs einer 
Werkstatt nach Abschluss der MaBnahmen zum Verbin- 
dungsaufbau zwischen Endgerat und Server die Komman- 
dos des fahrzeugspezifischen Diagnose-Protokolls iiber die 
Luftschnittstelle vom Server zum Endgerat iibertragen wer- 
den. Die fahrzeugspezifischen Diagnose-Protokoll-Kom- 
mandos werden dabei vom Diagnose-Server nach Identifi- 
zierung des zu diagnostizierenden Kraftfahrzeugs aus einer 
Datenbank ausgelesen. Das Endgerat setzt die iibertragenen 
Diagnose-Kommandos auf das Fahrzeugnetzwerk um. Die 
erfolgt beispielsweise dadurch, dass die empfangenen Kom- 
mandos in Kommandos fiir das diagnostizierende Steueige- 
rat umgesetzt werden und iiber die Schnittstelle zum Fahr- 
zeugnetzwerk, insbesondere iiber einen CAN-Bus, an das 
Steuergerat gesendet werden. Die Antwort dieses Steuerge- 
rats wird als Datennachricht aus dem Fahrzeugnetzwerk im 
entsprechenden Format iiber die Fahrzeugnetzwerkschnitt- 
stelle empfangen und wird dann vom Endgerat in Antwort- 
nachrichten fiir den Server umgesetzt. Diese werden dann an 
die Mobilfunkschnittstelle iibermittelt, die die Nachricht 
iiber ein vorgesehenes Ubertragungs-Protokoll (beispiels- 
weise im Rahmen des GSM-Standards) an den Server ge- 
schickt wird. Zusammenfassend setzt der Client im bevor- 
zugten Ausfiihmngsbeispiel also das vom Server iibertra- 
gene Diagnose-Protokoll (KWP2000) auf das CAN-Trans- 
port-ProtokoU um und umgekehrt. Die Ablaufsteuemng des 
beschriebenen Vorgangs zur Aufrechterhaltung der Dia- 
gnose-Kommunikation im Fahrzeug erfolgt im Endgerat 
autark, beispielsweise durch sogenannte Tester-Present- 
Nachrichten. Diese sind in der KWP2000-Spezifikation de- 
finiert und dienen der Erfiiliung der zeitlichen Anfordemn- 
gen der Fahrzeugnetzwerkes. Dadurch wird eine Entkopp- 
lung der zeitkritischen Diagnose-Kommunikation im Fahr- 
zeug von den zeitunkritischen Diagnoseablaufen im Server 
erreicht. Ergebnis ist somit eine flexible Konfiguration der 
fahrzeugspezifischen Diagnose-Kommunikation im Fahr- 
zeug, die nicht durch mogliche Probleme der Luftschnitt- 
stelle und der Diagnoseablaufe im Server belastet ist. 
[0025] Fig. 3 zeigt ein Ablaufdiagramm des Gesamtvor- 
gangs, der in fiinf gmndlegende Teilschritte gegliedert ist. 
Die detaiUierten Ablaufe innerhalb eines solchen Teilvor- 
gangs sind je nach Fahrzeugtyp, dem moglicherweise vor- 
liegenden FehlerfaU. und/oder der jeweiligen Implementie- 
mng des Systems im Diagnose-Server variierbar. Im ersten 
Schritt 100 erfolgt das Starten der Diagnose mit einer ent- 
sprechenden Anfrage an den Server. Die Aktivierung erfolgt 
dabei im bevorzugten Ausfiihmngsbeispiel durch den Fah- 
rer bzw. Nutzer des Kraftfahrzeugs der durch Anruf oder 
Ahnliches beim Service-Center eine Auffordemng des Ser- 
vers an den Client im Fahrzeug erzeugt, eine Diagnose- Ver- 
bindung aufzubaucn. Dcr Client baut dann die angcfordcrtc 
Verbindung auf. In anderen Ausfiihrungsbeispielen wird die 
Diagnose- Verbindung durch eine Anfrage vom Client aus 
aufgebaut. Der Aufbau der eigentlichen Diagnose- Verbin- 
dung erfolgt hier durch den Server oder den Client. Im nach- 
sten Schritt 200 erfolgt die Konfiguration der Femdiagnose- 
Funktionalitat im Fahrzeug durch den Server. Dabei wird 
die Ablaufansteuemng, die Transportschicht und gegebe- 
nenfalls die CAN-Kommunikation an das spezifische Fahr- 
zeug angepasst. Dies erfolgt durch Koimnandos bzw. Daten 
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vom Server, die dieser aus einer Datenbank fiir das spezielle 
Fahrzeug bzw. Fahrzeugtyp/und/oder Austattungsvariante 
ausliest. Bei der Aktivierung erhalt der Server beispiels- 
weise mittels eines Identifikationscodes Infomiationen liber 
das zu diagnostizierende Fahrzeug. Anhand dieser Informa- 5 
tion liest er fahrzeugspezifische Parameter aus der Daten- 
bank aus, die er dann an den Client zur Konfiguration der 
Femdiagnose-Funktionalitat iibermittelt. 
[0026] Nach den Teilschritten Aktivierung (100) und In- 
itialisierung (200) wird der Teilschritt Ausfuhrung des Dia- 10 
gnosevorgangs (301 bis 303) an einem Beispiel eines Steu- 
ergerats gezeigt. Zunachst wird im Schritt 301 durch den 
Server im zu diagnostizierenden Steuergerat, sofern dies 
notwendig ist, der Diagnosemode angestoBen, so dass das 
Steuergerat zum Ausfiihren der Diagnose-Funktion in der 15 
Lage ist. Ferner erfolgt die Mentifikation des Steuergerat, 
z. B. dessen Softwarestand zur Anpassung der Diagnose- 
Kommandos an den speziellen Steuergeratetyp. Auch dies 
ist optional und wird dann eingesetzt, wenn dies z. B. auf- 
grund der Vieizahi von Softstanden sich als erforderiich er- 20 
weist. Danach werden die ausgewahlten Diagnose-Kom- 
mandos vom Serv^er an den Client im Fahrzeug ubertragen. 
Beispiele fiir seiche Diagnose- Kommandos sind das Ausle- 
sen wenigstens eines Fehlerspeichers des betroffenen Steu- 
ergerats, das Auslesen von gespeicherten Umgebungs-Para- 25 
meter eines aufgetretenen Fehlers und/oder das Abfragen 
von zusatzlichen Ist-Werten aus dem entsprechenden Steu- 
ergerat. 

[0027] Im Schritt 302 setzt der Client das oder die uber- 
mittelten Diagnose- Kommandos auf das Fahrzeugnetzwerk 30 
um. Im darauf folgenden Schritt 303 wird die Antwort des 
Steuergerats auf das oder die gesendeten Kommandos, wel- 
che beispielsweise innerhalb einer bestimmten Zeitperiode 
auftreten muss, empfangen, vom Client iiber auf die Uber- 
tragungsschnittstelLe zum Server umgesetzt und an diesen 35 
zuriickgesendet. Die Schritte 301 bis 303 werden dann fiir 
jedes zu diagnostizierende Steuergerat oder, wenn die Dia- 
gnosekommandos einzeln nacheinander oder in Gruppen 
nacheinander versendet werden, fiir jedes einzelne Dia- 
gnose-Kommando oder Diagnose-Kommando-Gmppe wie- 40 
derholt. Ist die Diagnose fiir ein Steuergerat beendet, wird 
als Diagnose-Kommando ein Ende-Kommando gesendet, 
welches ggf. den Diagnose-Mode im Steuergerat deaktiviert 
und dieses wieder in den normalen Betriebsmode zunick- 
versetzt. 45 
[0028] Der vierte Teilschritt betrifft die Auswertung der 
erhaltenen Daten im Server (Schritt 400). Der Server wertet 
der nach MaBgabe eines ggf. spezifischen Algorithmus die 
gesammelten Fehlerinformationen aus, ermittelt ein Dia- 
gnose-Ergebnis und/oder Empfehlungen fiir das weitere 50 
Vorgehen. Im darauf folgenden Schritt 500 werden dann die 
vom Server ermittelten Ergebnisse an das Endgerat iibertra- 
gen und von diesem im Fahrzeug angezeigt. Dieser fiinfte 
Teilschritt stelle somit die Ergebnisausgabe dar. Im diesem 
Schritt ist auch in einem Ausfuhrungsbeispiel die Ubemiitt- 55 
lung und Anzeige einer Empfehlung fiir das weitere Vorge- 
hen im FehlerfaU vorgesehen, z. B. "Werkstatt aufsuchen", 
etc. 

[0029] Fig, 4 zcigt cin bcispiclhaftcs Kommunikations- 
szenario zwischen einem Femdiagnose-Server, einem Tele- 60 
matikendgerat und einem Steuergerat. Das Kommunikati- 
onsszenario stallt eine Realisierung des dritten Teilschritt in 
Fig, 3 im Detail dar. Basis der Kommunikation ist das nach 
ISO 14230-3 spezifizierte Diagnose-Protokoll KWP2000. In 
anderen Ausfiihrungsbeispielen werden herstellerspezifi- 65 
sche Varianten dieses Diagnose-Protokolls oder auch andere 
Diagnose- ProtokoUe entsprechend eingesetzt. Je nach Aus- 
fiihrungsbeispiel variiert die Abfolge der Schritte und der 
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Umfang der Schritte in den einzelnen Anwendungen. Fig. 4 
zeigt eine bevorzugte Realisierung der Kommunikation zwi- 
schen einem Femdiagnose-Server I, einem im Fahrzeug an- 
geordneten Telematikendgerat II und einem zu diagnostizie- 
renden Steuergerat IE. Die Kommunikation basiert dabei 
auf dem Diagnose-Protokoll KWP2000, welches in der ISO 
14230-3 spezifiziert ist. Die Fehlerermittlung und das Sct- 
zen der Fehlerspeicher erfolgt dabei in den meisten Falle 
durch bekannte Diagnosemethoden im zu diagnostizieren- 
den Steuergerat durch dort vorhandene oder dort eingele- 
sene Software. 

[0030] In Fig, 4 sind die einzelnen einer Kommunikation 

zwischen den drei beteiligten Einheiten dargestellt, wobei 
von oben nach unten eine zeitiiche Reihenfolge ausgedriickt 
sein soil. In den Einheiten sind Softwareprogramme vorhan- 
den, die die zu iibermittlenden Nachrichten erzeugen, aus- 
werten, etc. 

[0031] Nach Abschluss der Teilvorgange 1 und 2 (siehe 
Fig, 3, Schritte 100 und 200) wird in einem ersten Schritt S 1 
der Diagnose-Mode im zu diagnostizierenden Steuergerat 
aktiviert. Dazu sendet der Server ein entsprechendes Dia- 
gnose-Kommando (Start-Diagnostic-Session-Request). 
Dieses wird vom Endgerat empfangen und iiber die Schnitt- 
stelle zum diagnostizierenden Steuergerat weitergeleitet 
(Schritt S2) bzw. zuerst in ein fiir das Fahrzeugnetz geeigne- 
tes Format umgesetzt (z. B. mittels einer Tabelle) und dann 
auf das Fahrzeugnetz gegeben. Das zu diagnostizierende 
Steuergerat antwortet mil einer entsprechenden Antwort 
(Start-Diagnostic- Session-Response), die angibt, ob der 
Diagnose-Mode eingeleitet ist oder nicht. Diese Information 
sendet das zu diagnostizierende Steuergerat im Schritt S3 
zum Endgerat, welches wiederum im Schritt S4 (ggf. nach 
Umsetzung auf das vorgesehene Format) die Information 
zum Server iibertragt. 

[0032] Daraufhin wird zur Ablaufsteuerung und zur Erfiil- 
lung der Zeitanforderung im Fahrzeugnetz vom Endgerat II 
zum Steuergerat III im Schritt S5 eine Kommando geschickt 
(Tester-Present-Request), welches im Schritt S6 von Steuer- 
gerat mit einer entsprechenden Antwort (Tester-Present-Re- 
sponse) beantwortet wird. Diese Kommunikation wird im 
folgenden wahrend des Diagnosevorgangs dann ausgefiihrt, 
wenn vom Serv^er kein anderes Diagnose-Kommando wei- 
terzuleiten ist bzw. vom Steuergerat keine Antwort an den 
Server zu leiten ist. Daher konnen die Schritte S5 und S6 
auch mehrfach wiederholt werden, solange bis das erwartete 
Kommando vom Server empfangen wird. Tritt eines der ge- 
nannten Ereignisse nicht auf, wird die Kommunikation zwi- 
schen Endgerat und Steuergerat abgebrochen. 
[0033] Nach Empfang der Antwort im Schritt S4 sendet 
der Server im Schritt S7 ein Kommando (Read ECU-Identi- 
fication-Request), welches die Identifkation des zu diagno- 
stierenden Steuergerats anfragt. Dieses Kommando wird 
vom Endgerat empfangen und ggf. umgesetzt und dann im 
Schritt S8 zum Steuergerat iibermittelt. Das Steuergerat Uest 
aus seinem Speicher dai'aufliin wenigstens einen Identifika- 
tionsparameter aus und sendet diesen zum Endgerat (Read 
ECU-Identification-Response, Schritt S9). Diese Informa- 
tion wird dann ggf. nach Umsetzung vom Endgerat II im 
Schritt SIO an den Server iibcrtragcn. Anhand des Idcntifi- 
kationsparameters erkennt der Server das Steuergerat, gege- 
benenfalls dessen Software-Stand sowie gegebenenfalls das 
Fahrzeug und wahlt aus der Datenbank entsprechende Para- 
meter aus. In der Zwischenzeit lauft, wie anhand der Schritte 
Sll und S12 dargestellt, zwischen Endgerat und zu diagno- 
stizierenden Steuergerat die oben beschriebene Tester-Pre- 
sent- Kommunikation ab, die sicherstellt, dass die Kommu- 
nikation zwischen Endgerat und Steuergerat aufrechterhal- 
ten bleibt, das Steuergerat im Diagnosemode verbleibt und 
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keine Verletzung der Randbedingungen fiir die Kommuni- 
kation im Fahrzeugsnetz, die zum Abbruch fuhrt, erfolgt. 
[0034] In den nachsten Schritten werden die Fehlerspei- 
cher des zu diagnostizierenden Steuergerats ausgelesen. 
Dazu ubemiittelt der Server nach Empfang der Nachricht im 5 
Schritt SIO und Auslesen der steuergeratspezifischen Para- 
meter zum Endgerat im Schritt S 13 einc cntsprechendc An- 
frage (Read DTC>Request). In dieser Anfrage sind die steu- 
ergeratspezifischen Parameter enthalten, in denen z. B. an- 
gegeben ist, welche Fehlerspeicher auszulesen sind. Diese 10 
Anfrage wird im Schritt S 14 von Endgerat ggf . nach Umset- 
zung zum Steuergerat iibertragen. Das Steuergerat fiihrt die 
empfangenen Kommandos aus und sendet die Fehlerspei- 
cherinhalte als Botschaft Read DTC-Response im Schritt 

515 zum Endgerat. Die Botschaft Read DTC-Response ent- 15 
halt demnach die relevanten Fehlerspeicherinhalte. Die Ant- 
wort wird vom Endgerat ggf. nach Umsetzung im Schritt 

516 zum Server iibertragen. Daraufhin wird in den Schritten 

517 und S18 die oben erwahnte Tester-Present- Kommuni- 
kation zwischen Endgerat und Steuergerat bis zum emeuten 20 
Empfang einer Botschaft vom Server durchgefiihrt. 

[0035] Im darauf folgenden, optionalen Teilschritt werden 
die zu den Fehlereintragen gehorige Umgebungsparameter 
ausgelesen. Zu diesem Zweck sendet der Server nach Emp- 
fang der Botschaft im Schritt S16 und nach Auswertung der 25 
Fehlereintrage im Schritt SI 9 an das Endgerat eine entspre- 
chende Anfrage (Read- Freeze Frame-Request), die dieses 
ggf. nach Umsetzung im Schritt S20 an das Steuergerat wei- 
tergibt. Je nach Ausfiihrung liest das Steuergerat dann die 
gewunschten Parameter zu den gespeicherten Fehlem aus 30 
oder der Server spezifiziert anhand der Inhalte der Fehler- 
speicher den Inhalt seiner Botschaft, so dass mit dieser Bot- 
schaft nur bestimmte Umgebungsparameter angefordert 
werden. Das Steuergerat jedenfalls antwortet mit einer ent- 
sprechenden Antwort (Read- Freeze Frame- Response), in 35 
welchem die auf die eine oder andere Weise angeforderten 
Parameter enthalten sind. Im Schritt S21 wird die Antwort 
an das Endgerat gesendet, welches die Antwort wiederum 
ggf. nach Umsetzung im Schritt S22 zum Server iibertrag. In 
den Schritten S23 und S24 erfolgt emeut die Tester-Present- 40 
Kommu nikation . 

[0036] Im darauf folgenden Teilschritt, nach dem Fehler- 
speicher und zugehorige Umgebungsparameter ausgelesen 
und iibertragen sind, wird der Diagnosemode im Steuergerat 
deaktiviert. Hierzu schickt der Serv^er eine AufiForderung 45 
zum Beenden die Diagnosevorgangs (Stop-Diagnostic-Ses- 
sion-Request) an das Endgerat. Dieses gibt die Auflforde- 
rung zum Beenden an das Steuergerat weiter (Schritt S26), 
welches mit einem entsprechenden Antwortsignal (Stop- 
Diagnostic-Session-Response) im Schritt 27, mit welcher 50 
das Steuergerat die Beendigung des Diagnose-Modus mit- 
teilt, antwortet. Diese Information wird vom Endgerat im 
Schritt S28 zum Server iibertragen. Daraufhin (Schritt S29) 
werden die oben dargestellten Teilvorgange 4 und 5 beziig- 
lich Auswertung und Anzeige der Diagnose-Eigebnisse und 55 
ggf. -Empfehlungen weitergefiihrt. 

[0037] Das dargestellte Kommunikationsszenario ist ein 
Beispiel. In anderen Ausfiihrungen fehlen die Schritte zum 
Aktivicrcn und Dcaktivicrcn des Diagnosc-Modcs im Steu- 
ergerat und/oder zur Identifikation des Steuergerats und/ 60 
oder zum Auslesen der zugehorigen Umgebungsparameter. 
[0038] Die konkrete technische Realisierung der darge- 
stellten Kommunikation findet durch entsprechende Soft- 
ware-Programme in Server, Endgerat und Steuergerat statt, 
die jedes fur sich ebenfalls Teil der vorliegenden Erfindung 65 
sind. 
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Patentanspriiche 

1 . Verfahren fiir einen fahrzeugbezogenen Telematik- 
dienst, mit einem Zentralrechner (Server) und einem 
Endgerat, welches vorzugsweise im Kraftfahrzeug an- 
geordnet ist, zwischen denen eine Kommunikations- 
vcrbindung bestcht, dadurch gekennzeichnet, dass 
der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, welche wiederum auf Server und Endgerat aufge- 
teilt sind, wobei im Server zeitunkritische Funktionali- 
taten, im Endgerat zeitkritische Funktionalitaten ablau- 
fen. 

2. Verfahren fiir einen fahrzeugbezogenen Telematik- 
dienst, mit einem Zentralrechner (Sender), welcher mit 
einem Endgerat eine Kommunikationsverbindung auf- 
baut, dadurch gekennzeichnet, dass der Telematik- 
dienst in Teilfunktionalitaten aufgeteilt ist, wobei im 
Server zeitunkritische Funktionalitaten ablaufen. 

3. Verfahren fiir einen fahrzeugbezogenen Telematik- 
dienst, mit einem vorzugsweise im Kraftfahrzeug an- 
geordneten Endgerat, welches mit einem Zentralrech- 
ner (vServ^er) eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in 
Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat 
zeitkritische Funktionalitaten ablaufen. 

4. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass die zeitkritischen 
Teilfunktionalitaten autark im Endgerat ablaufen, die 
zeitunkritischen Teilfunktionalitaten vom Server mit- 
tels Kommunikatioon mit dem Endgerat durchgefiihrt 
werden. 

5. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass im Endgerat die 
zeitkritische Konmiunikation mit einem zu diagnosti- 
zierenden Steuergerat und/oder einer zu diagnostizie- 
renden Komponenten implementiert ist. 

6. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass der Telematikdienst 
eine Femdiagnose eines Kraftfahrzeugs ist und dass 
das Diagnose-ProtokoU im Server implementiert ist. 

7. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass Kommandos des 
fahrzeugspezifischen Diagnose-Protokolls iiber eine 
Luftschnittstelle vom Server zum Endgerat iibertragen 
wird. 

8. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass das Endgerat die 
iibertragenen Diagnose-Kommandos auf ein Fahrzeug- 
netzwerk umsetzt und die erzeugten Antwortnachrich- 
ten an die MobilfunkschnittsteUe iibermittelt. 

9. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, dass als Diagnose-Proto- 
koU KWP2000 oder eine Variante davon eingesetzt 
wird. 

10. Vorrichtung fiir einen fahrzeugbezogenen Telema- 
tikdienst, mit einem Zentralrechner (Server) und einem 
Endgerat, welches vorzugsweise im Kraftfahrzeug an- 
geordnet ist, zwischen denen eine Kommunikations- 
verbindung bestcht, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionahtaten aufgeteilt ist, 
welche wiederum auf Server und Endgerat aufgeteilt 
sind. 

11. Vorrichtung fiir einen fahrzeugbezogenen Telema- 
tikdienst, mit einem Zentralrechner (Server), welcher 
mit einem Endgerat eine Kommunikationsverbindung 
aufbaut, dadurch gekennzeichnet, dass der Telematik- 
dienst in Teilfunktionalitaten aufgeteilt ist, wobei im 
Server zeitunkritische Funktionalitaten ablaufen. 
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12. Vorrichtung fiir einen fahrzeugbezogenen Telema- 
tikdienst, mit einem vorzugsweise im Kraftfahrzeug 
angeordneten Endgerat, welches mit einem Zentral- 
rechner (Server) eine Kommunikationsverbindung auf- 
baut, dadurch gekennzeichnet, dass der Telematik- 5 
dienst in Teilfunktionalitaten aufgeteilt ist, wobei im 
Endgerat zcitkritischc Funktionalitatcn ablaufcn. 

13. Vorrichtung nach Anspruch 10 oder 11, wobei der 
Server iiber eine Luftschnittstelle mit dem Endgerat 
kommuniziert, dadurch gekennzeichnet, dass der Tele- 10 
matikdienst eine Femdiagnose eines Kraftfahrzeugs 
ist, wobei das Diagnose-ProtokoU als zeitunkritische 
Teilfunktionalitat im Server implementiert ist. 

14. Vorrichtung nach Anspruch 10 oder 12, wobei das 
Endgerat iiber eine Luftschnittstelle mit dem Server 15 
kommuniziert und welches eine weitere Schnittstelle 
umfasst, mit dem es mit einer zu diagnostizierenden 
Einheit verbunden ist, dadurch gekennzeichnet, dass 
das Endgerat als zeitkritische Teilfunktionalitat eine 
Ablaufsteuerung umfasst, die autark gegenuber der 20 
zentralen Recheneinheit ist und die die Diagnose-Kom- 
munikation im Fahrzeug aufrecht erhalt. 

15. Computerprogramm mit Programmcode-Mittein, 
um alle Schritte von jedem beliebigen der Ansprliche 1 
bis 9 durchzufuhren, wenn das Programm auf einem 25 
Computer ausgefuhrt wird. 

16. C^omputerprogrammprodukt mit Programmcode- 
mitteln, die auf einem computerlesbaren Datentrager 
gespeichert sind, um das Verfahren nach jedem beliebi- 
gen der Anspriiche 1 bis 9 durchzufuhren, wenn das 30 
Programmprodukt auf einem Computer ausgefuhrt 
wird. 
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